Effective Oct. 28, 2004, the Check Clearing for the 21st Century Act (“the Act”) improved the ability of banks to use electronic images of paper checks by, for example, submitting those images, along with associated information, for electronic processing. Under the Act, if a receiving financial institution (“RI”) or its customer requires a paper check, a paper image replacement document (“IRD”), such as a paper “substitute check,” can be created from an electronic check image and associated electronic information. Such a substitute check meeting specified requirements is the legal equivalent of an original paper check, and an RI is required to accept the substitute check for payment. This process enables banks to reduce the costs and inconveniences associated with physically handling and transporting original paper checks.
Under the Act, the substitute check must be essentially an exact copy of the original paper check to be the legal equivalent of the original paper check. In particular, the substitute check must include an exact copy of all of the Magnetic Ink Character Recognition (“MICR”) data provided on the original paper check and all check endorsements.
The terms “substitute check” and “IRD” generally are used interchangeably herein to refer to any electronic or paper document that can be used for electronic payment processing purposes, whether or not the document is the legal equivalent of a paper check negotiable instrument. The terms “bank,” “customer,” “RI,” and “processing entity” generally are used herein to refer to any party performing conventional or electronic check processing at any stage, including depositing and receiving institutions, their non-bank subsidiaries and affiliates, and any non-bank third party agents that provide processing services to banks.
Typically, each electronic check is received for processing in an electronic image cash letter file (hereinafter an “ICL file”), which includes one or more electronic image cash letters (“ICLs”). Each ICL includes one or more bundles of items to be processed. The term “item” is used herein to refer to a check or an IRD or information that represents a check or an IRD. For a particular item, the ICL can include one or more electronic images of the item, the complete MICR data provided on the item, and additional financial data related to the item, such as endorsement information (hereinafter, “addenda data”).
The ICL can further include a series of records related to the items. For example, for each bundle of items in the ICL, the ICL can include a bundle summary control record comprising information about the bundle, such as a bundle identification number, the number of items in the bundle, the value of each of the items in the bundle, and the total value of all the items in the bundle. The ICL also can include an ICL control record comprising information about the origin and destination of the ICL, and a cash letter bundle summary control record comprising a summary of all the bundle summary control records in the ICL. For simplicity, each ICL, bundle, item, image, record, or other component of an ICL file is referred to herein as an “element” of the ICL file.
Upon receiving an ICL file for processing, a processing entity typically validates the format and contents of the ICL file to ensure compliance with pre-designated formatting and content standards. Conventionally, the same formatting and content standards are applied to every ICL file received by the processing entity, regardless of any differences in the ICL files. Oftentimes, certain of the applied standards are appropriate for only some of the ICL files and not other of the ICL files. Therefore, some ICL files traditionally have been improperly rejected during validation for failure to comply with inappropriate validation standards.
Validation typically occurs at the ICL file, ICL, bundle, item, image, and record levels. Traditionally, if the validation fails at any of these levels, then the entire ICL file is rejected and returned to the bank that previously submitted the ICL file for processing. That bank must determine the reason why the ICL file was rejected, edit the ICL file to overcome the rejection, and resubmit the ICL file for processing. Such processing involves many inefficiencies, most notably the delay involved in resubmitting and revalidating ICLs, bundles, items, images, and/or records that did not cause the original rejection of the ICL file.
Thus, a need exists in the art for a system and method for efficiently validating ICL files. In particular, a need exists in the art for a system and method for validating ICL files using appropriate validation standards for each ICL file. A further need exists in the art for a system and method for allowing successfully validated elements of an ICL file containing one or more unsuccessfully validated elements to be processed for payment and/or presentment, where appropriate.